Communication and data-exchange between information systems within today's enterprises is increasingly based on a method known as an “Enterprise Service Bus” or an “ESB.” Conceptually, an ESB is an information processing system that serves as a central junction for receiving, routing, processing and forwarding information—in the form of formatted messages—between distributed enterprise systems. The standard method commonly consists of assembling components that receive, process and forward messages either via asynchronous constructs such as queues, or via synchronous constructs such as remote procedure calls.
Deficiencies in the standard method of creating and implementing an ESB manifest as a static rigidity in the configuration of components with respect to message pathways, and in the behavior of components with respect to the handling of messages. A limited amount of flexibility can be provided in message routing by inserting “return address/deliver to” destination information inside the messages. However, even with this technique, the actual message pathways are either static or temporary, and the messaging transport mechanisms (asynchronous, synchronous, Java Message Service, SOAP etc.) used by Enterprise Service Bus components are pre-determined and static.
While ESBs are touted as solving the interoperability problems among diverse network components, the static nature of these pathways and configurations in the current implementations of ESBs has resulted in the adoption of proprietary schemes for message transport and message handling. ESB products of different vendors may thus require mediation interfaces that translate one message handling scheme to another. These mediation interfaces are inherently customized and further add to the static nature of the ESB. To the extent that a network service is not adapted to communicate with the ESB, that network service is unavailable to the ESB and its users.
What would be useful is an implementation of an ESB that is adaptable in “real-time.” An “adaptable service bus” would be configurable in real-time to provide message transport and message handling for messages originating from a communication platform independent of the vendor of the communication platform and the communications protocol used by that platform.